However when I've checked the new crop fields for a0001-jmac_DSC1459.dng (from #139), I see the following results, which are off by 1 pixel:

ImageSizes(
    raw_height=2014, raw_width=3040, 
    height=2014, width=3040, 
    top_margin=0, left_margin=0, 
    iheight=2014, iwidth=3040, 
    pixel_aspect=1.0, flip=0, 
    crop_left_margin=16, crop_top_margin=8, 
    crop_width=3007, crop_height=1999)

Exiftool:

[TIFF-IFD0-SubIFD] DefaultCropOrigin            : 15 7
[TIFF-IFD0-SubIFD] DefaultCropSize              : 3008 2000

I am surprised that I've got the expected values in the case of the CR2 above, but get off-by-one values in case of this DNG.

In the added code I'm just exposing LibRaw's values. Could LibRaw return incorrect values in case of DNG? 🤔

I've just tried converting RAW_CANON_5DMARK2_PREPROD.CR2 to DNG with Adobe DNG Converter (17.1.0) and got this ImageSizes from the DNG:

ImageSizes(
    raw_height=3804, raw_width=5792, 
    height=3752, width=5634, 
    top_margin=52, left_margin=158, 
    iheight=3752, iwidth=5634, 
    pixel_aspect=1.0, flip=0, 
    crop_left_margin=336, crop_top_margin=112, # This differs from what I've got from CR2, for some reason it's *2 here
    crop_width=5616, crop_height=3744)

Exiftool of the DNG:

[TIFF-IFD0-SubIFD] DefaultCropOrigin            : 10 5
[TIFF-IFD0-SubIFD] DefaultCropSize              : 5616 3744

Hmm, not sure what's going on here.

Do you want to experiment a bit more?

I think I am out of ideas and it's working for my use-case: CR2s.

As I am just exposing what LibRaw is providing I fear that there's not much I can do.

At first I was optimistic about seeing nice results on CR2 and test data from other cameras, but that DNG with off by one error reduced my confidence in this patch.

It might be worth posting on the libraw forum, maybe it's an actual bug?

Good idea, will try accessing those crop values from LibRaw's CLI programs to compare with the ones I get in rawpy. Depending on findings it might be worth flagging on LibRaw forum.

I've checked cropped dimensions as reported by LibRaw against those exposed by this patch and they all match.

I've used LibRaw's (0.21.3) raw-identify -v and looked for line starting with Raw inset, width x height:

• RAW_CANON_5DMARK2_PREPROD.CR2
  • 5616 x 3744 left: 168 top: 56
• a0001-jmac_DSC1459.dng
  • 3007 x 1999 left: 16 top: 8
• RAW_CANON_5DMARK2_PREPROD.dng
  • 5616 x 3744 left: 336 top: 112

I'd say that this patch is working as intended - it's exposing values provided by LibRaw. Do you think this is good to be merged?

I will ask on LibRaw's forum about the off by one error and the DNG as it looks to be a bug on their side.

EDIT: Corresponding forum post for reference https://www.libraw.org/node/2838

Summary of replies from LibRaw forum: the off-by-one difference in the DNG is expected behavior caused by alignment to bayer pattern.

The DNG left, top padding difference was a bug and has been fixed with LibRaw/LibRaw@29d9785, and will be probably included in the next LibRaw release.

I've increased vcpkg's version in the Windows build script which should fix the previously failing Windows CI builds.

Looks good, great this even surfaced a bug in libraw! I'll merge it once CI ran through.